home *** CD-ROM | disk | FTP | other *** search
/ Netware Super Library / Netware Super Library.iso / mis_bnch / testdisk / testdisk.doc < prev    next >
Text File  |  1988-05-02  |  13KB  |  211 lines

  1.  
  2.                                    TESTDISK
  3.  
  4.               THE NEXT GENERATION OF DISK THROUGHPUT BENCHMARKS
  5.  
  6.  
  7.                             (c) COPYRIGHT 1988 BY
  8.                          COLUMBIA DATA PRODUCTS, INC.
  9.                         851 WEST S.R. 436, SUITE 1061
  10.                                 P.O. BOX 2584
  11.                       ALTAMONTE SPRINGS, FL  32714-2584
  12.                                (407) 869-6700
  13.  
  14.        Welcome to the world of hard disk performance measurement!  Until
  15.        recently, measuring  performance of  disk subsystems  for the IBM
  16.        PC/XT/AT/PS2 and compatibles has been somewhat over simplified by
  17.        the  industry.   Now,  with  the  introduction  of   SST-equipped
  18.        controllers, contemporary  benchmarks are  no longer  adequate to
  19.        predict  disk  subsystem  performance  in  actual  everyday  use.
  20.        Benchmarks for the  next generation of  mass storage systems  for
  21.        the  IBM  PC/XT/AT/PS2  and  compatibles  now  require  that more
  22.        variables  be  taken  into  account  to  accurately  measure  the
  23.        throughput a system can achieve.
  24.  
  25.                                  ACCESS TIMES
  26.  
  27.        Until now the only  major variable that generally  was considered
  28.        was the Average  Disk Head Seek  Time, expressed in  milliseconds
  29.        (commonly  referred  to  as  Average  Access  Time).   From   the
  30.        standpoint of a disk drive  manufacturer, this is the major  item
  31.        which is used to market their products and they are  consistently
  32.        touting faster and faster access times.  But the REALLY important
  33.        aspects of overall disk system performance are just not shown.
  34.  
  35.        Let's take a disk that has an access time of 20 milliseconds, for
  36.        example.   Does  that  mean  that  just  because  it  has  a   20
  37.        millisecond access time that it  is fast?  Well, yes and  no.  It
  38.        means that it can move the disk head from one spot on the disk to
  39.        another  spot  on   the  disk  in   an  overall  average   of  20
  40.        milliseconds.   As  far  as  access  times  go,  a 20 millisecond
  41.        average access time disk drive is relatively fast.  But it  tells
  42.        you nothing of  how fast it  will deliver data  to your computer.
  43.        So you  ask, "Well,  then, how  can I  tell when  a disk drive is
  44.        fast?"  Read on!!
  45.  
  46.        Disk performance really starts at your hard disk  controller--not
  47.        at your disk.  Disk performance is a function of how rapidly data
  48.        can be transferred from the hard disk into your computer.  If you
  49.        have a disk controller which  can move data at 29,000  characters
  50.        per second (which is not uncommon), then it stands to reason that
  51.        it  will  take  you  six  seconds  to load your 174,000 character
  52.        spreadsheet.  So, whether you have a 20 millsecond hard disk or a
  53.        65 millisecond hard disk, it  still takes six seconds to  recover
  54.        your spreadsheet!!
  55.  
  56.                                   DATA RATES
  57.  
  58.        As you  can probably  tell, disk  performance measurement,  which
  59.        tells you how long  you are going to  wait for something to  load
  60.        into your computer from your hard disk, can best be expressed  in
  61.        characters per second.  Since one character is equal to one byte,
  62.        and  most  disk  systems  move  data  in  thousands  of bytes (or
  63.        characters)  per  second,  the  standard  term  for  data rate is
  64.        kilobytes (1024 bytes) per second (KBS).
  65.  
  66.        Some benchmark tests  actually DO report  the data transfer  rate
  67.        (in KBS) of  the controller.  They  measure the movement  of data
  68.        from the disk to memory.  They only report, however, the  highest
  69.        data rate your disk drive can achieve on your computer.  Now,  if
  70.        you read closely,  you will notice  that I said  the HIGHEST data
  71.        rate your  disk drive  can achieve  on your  computer.  Does this
  72.        mean that there is more than one data rate expressed in KBS which
  73.        can be achieved by your disk system?  The answer is YES!
  74.  
  75.                               WHICH DATA RATES?
  76.  
  77.        Whenever the  disk system  is asked  to move  data from  the hard
  78.        drive  into  memory  or  vice  versa,  it takes time for the disk
  79.        system to figure out what you are asking for, where it is on  the
  80.        disk, and how to move the data.  This time lag is called  command
  81.        processing latency.  It is this  initial time lag before data  is
  82.        actually moved  to or  from the  disk that  is the  evil of  disk
  83.        performance.  Since this time lag  is pretty much a constant,  it
  84.        is wise to get  as much data off  of the disk at  one time rather
  85.        then to repeatedly ask for data in small blocks.  For example, if
  86.        you wanted  to move  327,680 bytes  off the  disk and the initial
  87.        command  processing  latency  was  70  milliseconds (70/1000 of a
  88.        second) and the 327,680 bytes  was moved in 512 byte  blocks, you
  89.        would be asking the disk to move data 640 times and your  command
  90.        processing  latency  alone  would  be  44.8  seconds  (640 X .070
  91.        seconds)!!
  92.  
  93.        If, however,  you moved  the 327,680  bytes off  the disk  65,536
  94.        bytes (64 KB)  at a time,  you would be  asking the disk  to move
  95.        data only 5  times and your  command processing latency  would be
  96.        35/100's of a second (5 X .070 seconds).  That is 992%  faster!!!
  97.        44.8 seconds compared  to a fraction  of a second  and that's not
  98.        even counting the time to move the data!!  This is extremely  eye
  99.        opening isn't it?
  100.  
  101.        So, you see, it  doesn't appear to be  very wise to ask  the disk
  102.        for data in small blocks, now does it?  But this is precisely the
  103.        way most application programs (such as Lotus, Dbase, etc) DO move
  104.        their  data--512  bytes  at  a  time.   Now,  these  other   disk
  105.        performance  testers  I  mentioned  test  the disk by moving data
  106.        65,536 bytes at a time.  So, you have absolutely no idea how fast
  107.        Lotus,  Dbase,  or  any  of  the  other  application programs can
  108.        retrieve data.  All you know, is that IF YOUR PROGRAM MOVED  DATA
  109.        64K AT A TIME  OFF THE DISK, THIS  IS HOW FAST IT  WOULD BE!!  In
  110.        essence,  then,  to  measure  disk  performance  in 64K blocks is
  111.        utterly useless to you if you  really want to know how fast  your
  112.        application program can load data.
  113.  
  114.        Your Columbia  Data Products  disk performance  tester, TESTDISK,
  115.        doesn't just move data off the disk in 64K blocks.  It moves  the
  116.        data in 8 different size blocks:  1/2K, 1K, 2K, 4K, 8k, 16K,  32K
  117.        and 64K.  This will give you  a clear idea of how fast  your disk
  118.        system really is.  When  you run this on  a disk system which  is
  119.        650 KBS at 64K  blocks, you may be  surprised to find that  it is
  120.        only 120 KBS (or less) at the 1/2K block rate.  You may even find
  121.        that you paid a  premium for a "fast"  disk system and you  never
  122.        will see the "speed" because the programs you run cannot  utilize
  123.        it.
  124.  
  125.        One last word  about average access  times.  They are  important.
  126.        We at Columbia Data Products  do not dispute that.  They  account
  127.        for a sizeable portion  of your command processing  latency.  You
  128.        should not, however,  pay a premium  for a "fast"  access time if
  129.        you  can't  take  advantage  of  it.   This  test  will  help you
  130.        determine that.  The last example I wish to give will compare two
  131.        hard drives.  The  first hard drive  has a 1  millisecond average
  132.        access time and  the other has  a 100 millisecond  average access
  133.        time.  The 1 millisecond access time hard drive can move data off
  134.        itself and  into the  computer at  100 thousand  bytes per second
  135.        (100 KBS).  The 100 millisecond  access time hard drive can  move
  136.        data off itself and into  the computer at 900 thousand  bytes per
  137.        second (900 KBS).
  138.  
  139.        To move 900  thousand bytes, the  1 millisecond access  time hard
  140.        drive takes 9 seconds while the 100 millisecond access time  hard
  141.        drive takes only 1 second.  Therefore, the 100 millisecond access
  142.        time hard drive is 9 times  faster moving data even though it  is
  143.        100 times slower moving its head!  It probably costs a lot  less,
  144.        too.  I think you are beginning to see the picture.
  145.  
  146.                                RUNNING TESTDISK
  147.  
  148.        To start testdisk, simply type TESTDISK and press  enter.  First,
  149.        you must choose whether or not you want to run testdisk in color.
  150.        Next, you will be asked whether or not your printer can print the
  151.        two  characters  which  are  displayed  on the screen.  A printer
  152.        which  can  print  the  IBM  character  set  will have no trouble
  153.        printing the displayed characters.  The printer will print out  a
  154.        graph of the  test results, if  you desire, at  the completion of
  155.        the test.
  156.  
  157.        You will then  be asked for  a DOS drive  letter (C:, D:  etc) to
  158.        test.  Next  you will  be asked  how much  data in  Kilobytes you
  159.        would like to read.  We recommend a minimum of at least 1000K for
  160.        an  accurate  test.   The   test  then  proceeds  to   perform  a
  161.        verification  pass  to  insure  that  the  area  being  tested is
  162.        error-free.  If it is not, an error will occur and the test  will
  163.        stop.  If it is error-free, the test will continue.
  164.  
  165.        The data is then read by two methods--SEQUENTIAL and  REPETITIVE.
  166.        The SEQUENTIAL test  will read data  from the drive  the same way
  167.        that your application program  will.  The REPETITIVE test,  which
  168.        reads data the way most "disk test" programs do, will not reflect
  169.        real world performance.  We have included the REPETITIVE test for
  170.        comparitive purposes only.
  171.  
  172.        TESTDISK creates a  graph of 16  individual tests, 8  SEQUENTIAL,
  173.        and 8 REPETITIVE.   Each individual test  reads data in  only one
  174.        block size.  The tests are  run in pairs (one SEQUENTIAL  and one
  175.        REPETITIVE) for block sizes of 1/2K, 1K, 2K, 4K, 8K, 16K, 32K and
  176.        64K.  In other  words, if you  are reading 1000K  in 1/2K blocks,
  177.        you will  access the  disk drive  2000 times  for each individual
  178.        test.  For the 1K test, you will access the disk 1000 times, then
  179.        500 times for the 2K test, 250 times for the 4K test, and so on.
  180.  
  181.        The  SEQUENTIAL  test  reads  the  disk one sector after another,
  182.        beginning with data in sector 1 on the hard drive.  To read  data
  183.        sequentially, the hard  drive head reads  all the sectors  on the
  184.        first track, then is moved from that track to the next track, and
  185.        so on, until the  amount of  data requested  is read.   The first
  186.        sequential test shows the  rate for reading the  requested amount
  187.        of data in  1/2K blocks, starting  in sector 1.   The second test
  188.        also begins in sector 1 and reads in 1K blocks, the third  begins
  189.        once again in sector 1 and reads in 2K blocks, and so on.
  190.  
  191.        The REPETITIVE read test is included to show how most other  disk
  192.        test  programs  read  their  data--repetitively, 64K  at  a time.
  193.        Rather than reading  the data sequentially,  as required by  most
  194.        application programs,  data from  the same  spot on  the disk  is
  195.        repeatedly read over  and over in  64K blocks.  Reading  the same
  196.        data repeatedly and in such large blocks does not accurately test
  197.        disk  performance   for  an   application  program.    Our  first
  198.        repetitive test  represents the  requested amount  of data  being
  199.        read from one spot  on the disk in  1/2K blocks, the second  test
  200.        shows the rate for reading the same data from the same spot in 1K
  201.        blocks, and so on, up to 64K.
  202.  
  203.                                   IN SUMMARY
  204.  
  205.        The sequential test results  will indicate your disk  performance
  206.        on user programs which call for  data from the disk.  Use of  the
  207.        repetitive test will show only what other test programs show.
  208.  
  209.  
  210.                                HAPPY TESTING!!
  211.